A bit of syntax that Svelte sorta has already (and that isn't easily found in the documentation) is this:

<!-- @component JSDoc-esque component documentation can go here. -->
<script/>
<style/>
<content/>

More to the point, I think using a comment is a bit... vague? I feel like it could cause edge cases. Instead, I would prefer something like this:

{@component foo}
<script/>
<style/>
<content/>

This keeps the intuition of the @component token for documentation comments.

Alternatively, you could use the proposed <svelte:template> syntax and instead nest the local component inside of a tag rather than using a comment or {...} mechanism. Doing this does very rapidly approaches the original inline components RFC, and nullifies the technically simpler concept behind this RFC, but still.

I was coming to find out if someone had an idea like this. I agree with the reasoning, even if I'm not 100% convinced it's strictly needed. It could make demos more concise too. I dislike using comments semantically, though I think we already have a solution built in, just need to repurpose it:

<script context="module">/* ... */</script>

<!-- This is a component accessible as <Foo> _inside_ this file only -->
<svelte:component name=Foo><!-- ... --></svelte:component>

<!-- This is a component accessible as <Bar> _inside_ this file only. It is exported by name as well. -->
<svelte:component export name=Bar><!-- ... --></svelte:component>

<!-- Any other content _outside_ the svelte:component remains the default export -->
<script>
  // Blah blah.
</script>

<Foo /> <!-- Didn't need to be imported since it's defined in-file -->
<Bar /> <!-- Didn't need to be imported since it's defined in-file -->

If you have an exported svelte:component the default export is optional.

One file, one component. It is simple, clean and prepare to reusable.

Yeah I caught myself thinking about small one-off modal templates today and wondering if frameworks (not just Svelte) should support inline/local components. Then I stopped myself.

1. The "exportability" concept has a smell. If you're just gonna export them anyways, may as well give them their own file the old-fashioned way.
2. Small, one-off things have a tendency to grow into bigger, needs-to-be-reusable things (in my experience).
3. I write Angular on the job and the only reason I've ever preferred templates over full-fledged components was because Angular components ALWAYS wrap their markup in a host element at runtime, so you cannot have recursive components that produce a flat DOM list, etc. Svelte components do not have this problem to start with.

Honestly this one seems like an antifeature to me, unless people can provide several examples where it's really useful. Seems like it would take quite a bit of work to implement.